Starting on windows#149
Conversation
Signed-off-by: Aloys Baillet <aloys.baillet+github@gmail.com>
aloysbaillet
force-pushed
the
add-windows-part1
branch
from
28993dc to
b591ba8
Compare
jfpanisset
left a comment
jfpanisset
left a comment
There was a problem hiding this comment.
Very exciting stuff, can't wait to see first officially published Conan Windows packages.
On Windows, you are using the same "build inside a container" approach as on Linux, although you aren't publishing containers (that I can tell), just the resulting Conan packages, right? For Linux building inside a container is required to get a CentOS 7 / VFX Platform like start point (instead of the Ubuntu environment provided by GHA runners). Since there's a lot less variability on the Windows platform, would it make sense instead to build directly on the VM, just installing / specifying the VS Code version you want, and thus save the non-trivial overhead of large Windows base container images?
I imagine that supporting "native" builds will be non trivial, but will likely be needed to support building Conan packages on macOS.
| def _configure_cmake(self): | ||
| cmake = CMake(self) | ||
| cmake.definitions["GCC_INSTALL_PREFIX"] = os.environ["GCC_INSTALL_PREFIX"] | ||
| if platform.system() == "Linux": |
There was a problem hiding this comment.
May end up being:
and platform.system() != "Windows"
| with self._build_context(): | ||
| autotools = self._configure_autotools() | ||
| autotools.make() | ||
| if system() == "Linux": |
There was a problem hiding this comment.
match / case when when we switch to Python 3.10 and support Darwin/macOS
|
|
||
| [storage] | ||
| path = ../d | ||
| download_cache = /tmp/downloads |
There was a problem hiding this comment.
That looks like a Linux-specific path?
| version = version_info.ci_common_version | ||
| major_version = utils.get_major_version(version) | ||
| versions_to_bake.add(version) | ||
| if platform.system() == "Linux": |
There was a problem hiding this comment.
match / case with Python 3.10 / macOS support
|
|
||
| RUN choco install --no-progress --yes visualstudio2017buildtools --version=15.9.41.0 | ||
| RUN choco install --no-progress --yes visualstudio2017-workload-vctools --version=1.3.1 | ||
| RUN choco install --no-progress --yes --execution-timeout=0 visualstudio2017-workload-manageddesktop --version=1.2.1 |
There was a problem hiding this comment.
VFX Platform now specifies Visual Studio version: 2017 for CY2021, "Visual Studio 2019 v16.9 or later" for CY2022,
so version of Visual Studio to be pulled from Chocolatey should be in a more generic CY20XX config YAML?
There was a problem hiding this comment.
Good point, I've been trying to use the ci-common for the low-level toolchain, but the versions change at different rates for windows and linux, such a pain :(
|
|
||
| RUN iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1')); \ | ||
| $env:Path += '";C:\tools\python3;C:\tools\python3\Scripts"'; \ | ||
| choco install --no-progress --yes python3 --version=${Env:ASWF_CONAN_PYTHON_VERSION} --params '"/InstallDir:C:\tools\python3"' |
There was a problem hiding this comment.
Should the version of Python 3 be specific to the VFX Platform CY20XX, or is this just for build purposes and won't end up in the build artifacts?
| # variables available | ||
|
|
||
| LINUX_CONAN_USER_HOME = "/tmp/c" | ||
| WINDOWS_CONAN_USER_HOME = "C:\\tmp\\c" |
There was a problem hiding this comment.
On Windows the system defined %TEMP% directory is typically C:\Users\User Name\AppData\Local\Temp aka %USERPROFILE%\AppData\Local\Temp, although I've seen a lot of local installs use C:\Temp which goes back to very old versions of Windows.
| self.assertTrue( | ||
| cmds[2].endswith( | ||
| f"conan create {constants.CONAN_USER_HOME}/recipes/openexr openexr/2.3.0@aswftesting/vfx2019'" | ||
| f"conan create {os.path.join(self._docker_home, 'recipes', 'openexr')} openexr/2.3.0@aswftesting/vfx2019'" |
There was a problem hiding this comment.
Good change to not build paths yourself. Could be interesting exercise to grep for / in the whole codebase (you may have already done that).
|
Thanks JF! I think using a windows container has at least these 2 nice advantages:
That said, once we have the packages built and uploaded to Conan, I don't see much value in using containers to download and use the packages, I don't expect client repos to use docker for windows builds. Happy to discuss at the next CI meeting. |
2 participants
Added windows Dockerfile which can already build a few packages, I've tested ninja and cmake for now.
N.B. that building clang from source makes little sense as binaries are already available for windows. Building python from source also makes little sense... We need to think about which packages we really want to handle properly in Conan.